Fixes #4757

问题

packages/services/service-storage/src/attachment-access-hooks.ts 的 beforeDelete 守卫用两条路径解析「这次删除命中了哪些行」——按 input.id,或按 input.options.where——然后 if (!rows.length) return。

既没有 id 也没有 where 的删除两条分支都不进,rows 保持为空,守卫返回放行。但这不是「没命中任何行」,而是从来没有查询过 —— 两者是不同的判断,把后者当前者就是典型的 fail open。

engine 那边把同一次调用当作全表批删:packages/objectql/src/engine.ts 的 delete 路径在没有标量 id 时把 AST 播种成 { object }(没有 where),再交给 driver.deleteMany。于是 ql.delete('sys_attachment', { multi: true }) 会清空整张附件表,而记录级守卫恰好授权了零行。

下面两层都接不住:

• plugin-sharing —— buildWriteFilter 对没有 owner 字段的对象返回 null,而 sys_attachment 的来源列是 uploaded_by 不是 owner_id,所以 AST 上不会被合成任何行级作用域谓词。
• plugin-security —— member_default 基线不带 allowDelete(ADR-0090 D5),普通成员会先被 RBAC 拒掉;但只要 app 发了一份带 sys_attachment 删除位的领域授权(附件面板本来就需要,attachmentsFixture 的 att_attachment_manager 正是这么建模的),就能通过 RBAC 直接落到这条没有守卫的路径上。

改动

按 issue 的建议失败关闭,姿势照抄 #4630 给 sys_comment 立的 resolveTargetRows:无 id 且无 where ⇒ 403 ATTACHMENT_DELETE_DENIED,而不是穿过空 rows 短路。

合法路径完全未动,这一点专门写了回归用例:

• 按 id 删除 —— 照旧逐行做 uploader-or-parent-editor 判定;
• 带 where 的多行删除 —— 照旧解析匹配行集合(1000 行上界不变)并逐行判定;
• where: {} —— 它匹配所有行,但是一次真实查询,所以仍然走「逐行授权」而不是「拒绝」:每一行都过才放行,有一行不过就 403;
• 谓词跑了但一行都没匹配到 —— 仍然放行(这才是真正的「没有东西需要授权」);
• isSystem 与无 session 的程序化调用 —— 旁路不变。

.changeset/attachment-unscoped-multi-delete.md 里写了迁移说明:如果确有清空附件表的需求,传谓词({ multi: true, where: {} },逐行授权)或者在 system context 下做。

测试

packages/services/service-storage/src/attachment-access-hooks.test.ts 在既有 beforeDelete 用例旁边新增一组 #4757 用例。先验证过它们在未修复的源码上会红(回退 src、保留 test:5 failed | 16 passed),打上修复后:

pnpm --filter @objectstack/service-storage exec vitest run --maxWorkers=2
 Test Files  19 passed (19)
      Tests  260 passed (260)

类型侧:该包在 scripts/check-type-check-coverage.mjs 里是 DEBT 条目(42 errors,没有 typecheck 脚本),tsc --noEmit 实测仍是 42,本次改动的两个文件零错误;pnpm --filter @objectstack/service-storage build(含 DTS)通过。

同形状排查(issue 末尾那句)

按要求全仓扫了一遍「没解析到行 ⇒ 放行」这个形状(beforeDelete 与 beforeUpdate 一类守卫,检索 registerHook('before*'、input?.id、options?.where、if (!id) return、if (!rows.length) 等)。发现的其它位置都没有在本 PR 里修,按 Prime Directive #10 另立了未认领 issue:

• 审批记录锁 bindApprovalLockHook 对谓词式(multi)更新完全失效:if (!id) return 把「没解析到行」当成「允许」 #4778 —— plugin-approvals 的审批记录锁 bindApprovalLockHook:beforeUpdate 开头 const id = ...; if (!id) return;,而 engine 只在 where.id 是标量时才提取 input.id,所以任何 multi: true 的谓词式更新都直接绕过 RECORD_LOCKED。这是本次排查里最实的一条,和 installAttachmentAccessHooks does not authorize an UNSCOPED multi-delete: no id + no where reads as "nothing to authorize" and deleteMany runs over the whole table #4757 是同一个错误推理。
• 共享规则 hook 对谓词式(multi)写入不重算:if (!id) return 让 sys_record_share 授权在批量更新后变陈旧 #4779 —— plugin-sharing 的 rule-hooks:afterInsert/afterUpdate 同样 if (!id) return,批量更新后 sys_record_share 不重算,本应被收回的共享行留在表里(授权侧的陈旧 fail open)。里面留了一个需要维护者裁定的点(超上界时拒绝写入还是告警补偿)。

以下位置形状相同但不是授权守卫,后果是数据/可观测性而非越权,且多数在注释里已声明为已知边界,只在 #4778 正文里记录、未单独立 issue:plugin-audit 的 captureBefore(批量写不留审计快照,注释写明「too costly」)、plugin-webhooks/plugin-email/plugin-sharing 三处 provenance 盖章(注释均写明 known boundary)、plugin-sharing 的 primary-bu-projection beforeDelete(投影 best-effort,靠下次写入或 boot backfill 自愈)。

明确排除的:plugin-auth 的 identity-write-guard —— 它的 beforeDelete 是无条件拒绝、beforeUpdate 走字段白名单,不依赖行解析,不属于这个形状。

范围

改动只落在 packages/services/service-storage/。issue 正文引用的 packages/objectql/src/engine.ts delete 路径只作为背景阅读,未改动(本轮 #4769 正在改 objectql);plugin-auth、service-automation、plugin-approvals 也只读未改。

Generated by Claude Code